Pull request overview

This PR fixes FileHandler (/file/:key) so it stops processing immediately after writing an error response, preventing additional work (e.g., DB lookups, Referer parsing, manifest generation) and avoiding multiple unrelated errors being appended after the response is committed.

Changes:

• Add early return statements after each error response in FileHandler.
• Replace raw HTTP status codes with net/http status constants.
• Add a regression test ensuring an invalid token does not trigger downstream DB access or additional error messages.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Good catch — the missing return statements after error responses meant the handler would fall through and try subsequent operations with invalid state (e.g., calling GetInfra after JWT validation failed, or parsing a URL from an empty referrer). This could lead to confusing cascaded errors in logs and potentially writing multiple response bodies.

The fix is straightforward: add return after each error response. The switch from magic numbers (500, 200) to http.StatusInternalServerError / http.StatusOK is a nice cleanup too.

The test verifies the key behavior: an invalid JWT token should produce a 500 response with the JWT error message and NOT proceed to call MongoDB or parse headers. The AssertNotCalled on the mock operator confirms the early return works.

One small observation: the err.Error() written to the response body on JWT validation failure could leak internal details to the client (token parsing error messages). For a production API you'd typically want a generic error message in the response and the detailed error only in logs. Not a regression from this PR though — it was already the pattern before.

LGTM.